-
Notifications
You must be signed in to change notification settings - Fork 204
Add proposer duties v2 endpoint #563
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
can we clarify this? When is it required from? clearly its missing fulu... is that ok? |
|
Will be required from Gloas, so that we can then deprecate v1. |
ok great - thats perfect. We can get it done earlier but it's missed our fulu release is all and it does concern me when i can't implement a 'required' endpoint... |
rolfyone
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm just a nit because we're tagging as required, we should put in description when it's required from to be clear.
Adds proposer duties v2 endpoint which works the same as v1 but uses previous epoch to determine dependent root to account for deterministic proposer lookahead changes in fulu. ethereum/beacon-APIs#563
|
now that i've actually implemented the dependent root change for fulu for teku, i do wonder if a new endpoint is correct or if we just need a better understanding of why this dependent root is different in fulu @michaelsproul... maybe the better option is understanding that for the block proposals dependent root either 1 or 2 epochs prior are equally valid, and its just differing opinion on implementations.... I think that we'd probably need to 'hack' dependent root in teku now that it is computing proposer duties using lookahead... |
From a validator client perspective it doesn't make much of a difference but it avoids reorging duties in some edge cases. If I remember correctly the demand came from out of protocol (Lido?) because they need consistent responses from each CL client so it would be good if we can come to consensus what dependent root to return and imo current behavior of v1 endpoint is incorrect post-fulu. Is the problem in teku just that you need to handle both cases (pre/post fulu)? |
i can lie like lighthouse is going to in post fulu world, its just not the acutal dependent root so im appreciating what sprouls point was now that i see it |
Adds proposer duties v2 endpoint to account for deterministic proposer lookahead ethereum/consensus-specs#4190 and return a different
dependent_rootbased on current fork (pre/post fulu).NOTE: this endpoint is not part of fulu release and is only required for gloas, it cannot be relied upon before that as clients might not have implemented it.